Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / iesg / iesg.92-03-26 < prev next >

Wrap

Text File | 1993-02-04 | 12.2 KB | 342 lines

IETF STEERING GROUP (IESG) REPORT FROM THE TELECONFERENCE March 26th, 1992 Reported by: Greg Vaudreuil, IESG Secretary This report contains - Meeting Agenda - Meeting Attendees - Meeting Notes Please contact IESG Secretary Greg Vaudreuil for more information. Attendees --------- Almquist, Philip / Consultant Borman, David / Cray Research Chiappa, Noel Crocker, Dave / TBO Crocker, Steve / TIS Coya, Steve / CNRI Estrada, Susan / CERFnet Gross, Philip / ANS Hinden, Robert / BBN Hobby, Russ / UC-DAVIS Huizer, Erik / SURFnet Piscitello, Dave/ Bellcore Vaudreuil, Greg / CNRI Regrets Davin, Chuck / MIT Reynolds, Joyce / ISI Stockman, Bernard / SUNET/NORDUnet 1. Administrivia 1.1 Bash the Agenda 1.2 Approval of the Minutes 1.2.1 February 20th 1.2.2 March 5th 1.3 Next Meeting 2. Review of Action Items 3. Protocol Actions 3.1 The PPP Authentication Protocols 3.2 PPP Link Quality Monitoring 3.3 SNMP Authentication 3.4 BGP NEXT-HOP-SNPA Attribute 3.5 Interdomain Policy Routing 3.6 MD2, MD5 Documents 3.7 Multipurpose Internet Mail Extensions 4. RFC Editor Actions 4.1 HYBRID NETBIOS END-NODES 5. Working Group Actions 5.1 Network Access Server Requirements (nasreq) 6. Technical Management Issues 6.1 ROAD Follow-on 6.4 IDRP over IP MINUTES 1. Administrivia 1.1 Bash the Agenda The agenda was approved as written. 1.2 Approval of the Minutes 1.2.1 February 20th The IESG approved the Minutes of the February 20th teleconference for public distribution. 1.2.2 March 3rd The IESG deferred approval of the March 5th minutes. 1.3 Next Meeting Eric Huizer has asked that the IESG consider moving its teleconference time so that it no longer conflicts Thursday Evenings with personal obligations. The IESG was open to the suggestion, and tasked Steve Coya to juggle schedules to find a new meeting time. ACTION: Coya -- Poll the IESG and determine if there is a meeting time available for teleconferences other than Thursday 12-2 EST. The next IESG teleconference was scheduled for Thursday April 2nd from 12-2 PM EST. This meeting will be a single topic meeting to resolve the outstanding administrative issues relating to the creation of IETF work items for making progress with Routing and Addressing. 2. Review of Action Items The actions items were not reviewed during this meeting. 3) Protocol Actions 3.1 The PPP Authentication Protocols The IESG reviewed the PPP Authentication protocols document. This document describes a framework and specific protocols for simple password and more rigorous challange-response authentication. The IESG approved this document pending two events. The document itself needs work editorial work in several places to improve the clarity and the document required the publication of the MD5 Message Digest algorithm as an RFC before it can be referenced by this document. ACTION: Vaudreuil -- Send a recommendation to elevate the PPP authentication protocols to Proposed Standard as soon as 1) The MD 5 message digest algorithm document is submitted to be published as an RFC, and 2) A new version of the Authentication Protocols document is submitted clarifying several editorial points. 3.2 PPP Link Quality Monitoring The PPP Link Quality Monitoring document reflects a significant redesign of the original mechanism outlined in RFC 1171. This new mechanism has been implemented and texted and reflects lessons learned and has been tested and implmented. The IESG approved this document for Proposed Standard. ACTION: Vaudreuil -- Send a recommendation to elevate the PPP Link Quality Monitoring document to Proposed Standard. 3.3 SNMP Authentication The IAB has discussed the SNMP Authentication documents and has asked the IESG for further discussion. Two issues were raised. First were some relatively minor technical errors which can be easily corrected, and second, the documents do not appear to meet the IAB's normal standard for quality writing. The IESG discussed both of these points. On the first point; The specific technical points were not clearly communicated to the IESG, however the IESG expressed dismay at hearing these objections at this late time, after a through public review and a last call period. The IAB is working directly with the authors to resolve these points. The harder question for the IESG was the document writing style itself. The IESG recognizes the the quality of documents is quite variable. The IESG has had the practice of approving proposed standard documents if there are no glaring technical errors, and the document meets the requirements for formatting and gramatical correctness. Reviewing documents for writing style and clarity is difficult. POSITION: As long as a Proposed Standard document is technically acceptable, the writing is readable to the extent necessary to implement from. and the document reflects a best effort given the limited resources of the IETF, the IESG will approve such a document. 3.4 BGP NEXT HOP SNPA Attribute The IAB has discussed the BGP Next Hop SNPA Attribute and has asked the IESG for clarifications on several points. The specific question the IAB raised concerns the behavior of the attribute across different networking technologies, especially across multi-media bridges. The IESG discussed and agreed to ask the working group to re-examine the intended scope of this protocol. The IESG also discussed the implications of operating a protocol like the SNPA attribute across a multi-media bridge, and concluded that this is not a real concern at this time. Multi-media bridges have not yet been architected into the system and many protocols break across them, not just this one. ACTION: Hinden -- Begin a dialogue with the the BGP working group to explore the intended scope of the BGP Next Hop SNMP Attribute. 3.5 Interdomain Policy Routing The Interdomain Policy Routing Working Group has asked the IESG to consider IDPR for Proposed Standard. The IESG agreed that it is appropriate to standardize IDPR according to the proceedures documented in RFC 1264. A last call will be issued once the final version of the protocol, as well as the required reports are submitted to the Internet Drafts directories. One of the reports that IESG has asked for is a discussion on the interworking of IDPR with BGP in the Internet. ACTION: Vaudreuil -- Send a last call for IDPR once the final version is posted as an Internet Draft. ACTION: Hinden -- Communicate with the IDPR Working Group the need for updated documents and reports before approval for Proposed Standard. 3.6 MD2, MD5 Documents Several Security related protocols reference the MD2 and MD5 Message Digest Algorithms. These algorithms are documented in Internet Drafts that should be published as informational RFC's. There is new text for both of these documents. ACTION: Vaudreuil -- After new text is submitted to the Internet Drafts, send a notification to the RFC Editor that the documents are ready to be published as RFC's. 3.7 MIME The Internet Mail Extensions Working Group has submitted a revised version of MIME to the Internet Drafts directory and has asked the IESG to consider it for Proposed Standard. The new version reflects the changes requested by the IESG. The IESG has received an objection from EUnet, a network con sortium analagous to UUnet. They object to the separation of the Mnemonic character set proposal from the main MIME standard. The IESG discussed this objection, but concluded that the specific objections could not be accommodated in the current document due to rules for citations, but that the functionality requested could still be achieved via registration of the mnemonic character set with IANA. ACTION: Hobby -- Send an IESG response to the EUnet objections. The IESG discussed the changes, and approved MIME for Proposed Standard, providing that a second last call is issued and no new serious issues are uncovered. ACTION: Vaudreuil -- Send a second last call to the IETF list for MIME soliciting any objections to the changes in the current draft. 4.0 RFC Editor Action 4.1 NETBIOS over TCP Fredrick Noon was contacted by the IESG Secretary and was asked to clarify the intended status for the protocol. He has responded that he would like the document to be entered on the standards track. ACTION: Vaudreuil -- Send note to Postel taking the Netbios document into the standards process. The IESG discussed the need for community review, but was not able to resolve the question of whether an IETF Working Group would be the best place to review this proposal. ACTION: Borman -- Do some intellegence gathering, determine the constituency, and determine whether a working group or a one-shot BOF is necessary for review of the Netbios over TCP document. Determine if Noon is willing to chair a working group or BOF to review this protocol. 5.0 Working Group Actiosn 5.1 Network Access Server Requirements The IESG has reviewed the nasreq working group. Steve Kent raised a question of overlap between this group and others with similar sounding charters which pointed out that the scope of the group is not well defined. A new charter which more clearly specifies the work to be accomplished is needed. ACTION; Hobby -- Work with the prospective chairman of the nasreq working group to refine the scope of the Working Group and generate a new charter. 6.0 Technical Management Issues 6.1 Routing and Addressing The ROAD group, chartered by the IAB has given its recommendations to the IETF for future work in Routing and Addressing. The IESG began discussions on a workplan to solve the routing and addressing issues facing the Internet. 6.1.1 Class B Number Assignment The Class B numbers are being consumed at a high rate. It is clear that they will run out in the near future. While the IETF works on a plan for extending the class B address space, policies for the assignment of network addresses need to be made. This IESG discussed several ideas including charging for the cost of assigning and routing IP addresses, but did not reach resolution. There was a clear sense that the IETF "ownes" this problem and that work should begin on formulating assignment guidelines. 6.1.2 Short Term Addressing There are two proposals on the table for resolution of the Class B depletion problem, C-Sharp (C#), a creation of additional Class B numbers, and CIDR, Classless Interdomain Routing. Both proposals appear to address the short term needs, but have relative advantages and dis-advantages. C# mostly solves the C# of B address problem but does not address the aggragation of addresses necessary to contain the routing table explosion. The immediate need to work on a single solution requires a choice of one of these proposals to pursue. The decision on the choice of Cider vs C# depends on projections on when the addresses will run out. These numbers have not been made available to the IESG. The numbers used by the ROAD group in crafting their recommenation for CIDR are statistically sensitive projections and as such there is a reluctance to release the numbers to a wider community. The IESG discussed the tension between the need to move forward rapidly on this issue and the demands for openess. This tension results from the dual responsiblity of the IESG for both the operational stability of the Internet and the need for complete and accepted standards. The IESG will continue this discussion in a single topic teleconference April 2nd. 6.4 Dual IDRP An effort to begin work on Dual IDRP (ISO BGP) has begun in the noop Working Group. This work needs to procede in the Routing area, but is not clear whether is should be in the IS-IS working group or a new Dual IDRP Working Group. ACTION: Hinden -- Find a home for the Dual IDRP work in the Routing Area.